1. Field of the Invention
This invention relates generally to the field of Electronics Design Automation (EDA) systems, and more specifically, to EDA systems used for systems design and testing of systems based on microprocessors, peripherals, special purpose functional macros, and user specific custom logic.
2. Background
Modern electronics systems increase in complexity with each new generation. System development time tends to increase as a function of system complexity. Simultaneously, competitive pressures require ever shorter development and time to market cycles, making time-to-market a critical success factor in the industry. Product life cycles are also getting shorter. Thus, customers require more complex products, which take more time to develop, but market pressures dictate that the products be developed in much shorter cycles than ever before.
Additionally, many electronics designers are asked to build chips that include on one chip not only the microprocessor, but also several peripherals that may be needed for an embedded target application. As an example, some of the microelectronics controls that are built into space vehicles, airplanes, new cars or even appliances might include a chip that has a microprocessor, several analog to digital or digital to analog converters, a hard disk controller, possibly some other peripherals, custom user hardware logic as well as application software to cause the chip to perform the specific functions for the target application. If there is an error in the design that causes the system to malfunction, it can cost as much as $100,000 or more to "re-spin," that is, re-layout the chip, manufacture it, etc. to correct the problem.
Designers are thus being asked to build more complex chips, for lower costs, in less time than ever before, while also reducing the risk of errors which might necessitate the expense of a "re-spin."
In a typical system design, the hardware designers will put together a hardware prototype, using the final outline of the system specification and logic design. Software designers will typically write the application software. Once the hardware prototype is in place and the application software is ready, it is necessary to operate the hardware with the application software. For example, a chip that manages fuel-injection in an automobile engine may have a microprocessor connected to several analog to digital (A/D) and digital to analog (D/A) converters that are, in turn, attached to sensors attached to fuel pressure gauges, oxygen sensors, engine temperature sensors, etc.
Most microprocessors are fairly general purpose--that is, they have sets of instructions that they can handle, such as add, subtract, multiply, divide, load registers, etc. To make such a microprocessor actually manage fuel-injection, the application software specifies combinations of instructions to be executed by the microprocessor. For example, the application software may determine the sequence in which inputs are analyzed, cause the microprocessor to compute certain outputs, such as the amount of fuel to be released next, how much time an injector has to be open to cause the fuel to be released, and then tell the microprocessor to signal that this is to be done by a specific injector. Signals are converted and sent through the peripherals that control or operate that injector, and the fuel is released for the calculated time period. If the fuel pressure is still not at the desired level, the sensors measuring this will signal that to the microprocessor and the process continues.
If this is the type of system under development, a hardware prototype is built and tested, while application software is being developed and tested on other machines. At some point the hardware prototype has to be operated with the application software, to see if it all works. The process of evaluating newly designed hardware with new application software is known as systems integration.
The first time system integration takes place, it is very probable that the complete system will not function properly. When the system malfunctions, the cause could be any of its elements. For example, the microprocessor might have a design flaw in its floating point arithmetic logic that causes errors with certain kinds of large numbers. Or, the application software might have a "bug" or defect in the way it analyzes input. Or, the custom hardware user logic that controls the sensor readings might be defective. Sometimes the defect may cause results that are hard to interpret, and thus hard to "debug."
In the fuel-injection example, if too little fuel is being released, is it because the hardware is in error (and if so, is it the microprocessor or one of the A/D converter peripherals, or the system interconnect or the custom user logic?) or because the application software is in error (and if so, where and in what set of circumstances?) or is it a combination of two or more elements? Figuring out what causes the problem is the art of "debugging." If the designer has a guess about what the cause of the flaw or bug might be, it would be desirable to be able to isolate the problem, recreate all the conditions exactly as they occurred at the time the error was noticed, and try to see which element caused the bug and what can be done to fix it.
The earlier that each element is debugged, and the earlier that systems integration and systems-level debugging can be done in the development cycle, the faster the product will get to market. However, if the designer tries to move too quickly, and the product is fixed in final form before all the significant bugs have been removed, it can lead to costly re-spins, and loss of customer satisfaction in the market.
To help achieve these goals, many design, development, testing aids and rapid prototyping aids have been developed. Most of these, however, are limited in function and apply to only to one or another subset of design questions, usually not to the system under development as a whole, nor to the whole cycle from development to field test and final product.
For example, one of the most time consuming steps in system design is the creation of hardware prototypes for use in testing whether the new systems meet their concepts and design specifications. Another time consuming step, as mentioned, is the testing and debugging of the system as a whole, including both its hardware and any operating system or driver software. Additionally, the system under development also needs to be verified with real application software running at real-time clock frequencies and in real application conditions, a test process usually known as in-system verification. Finally, a decision has to be made about fixing the product in its final form for field test, market acceptance and production shipping.
Presently, there are tools available for testing some of these functions, but as noted, most of these are limited to testing only a subset or part of the system and they tend not to be integrated with the other subsets. For example, in-circuit emulators (ICE systems) exist, for some systems, that will emulate the microprocessor being developed so that the software can be tested. However, ICE systems usually only emulate the microprocessor, not the entire hardware system, including its peripherals. ICE systems also may require special chips known as bondout chips, for microprocessor emulation. These have special bondouts so that readouts can be taken of various internal states in the chip, such as register contents, etc.
Bondout chips are very expensive to make, and as chips become more complex in design, it becomes less and less viable to build special bondout chips to emulate them. Bondout chips, in some cases cost as much as one to two million dollars, or more, in additional chip design costs. While bondout chips can be built fairly easily for 8 or 16 bit microprocessors, as the microprocessor approaches 32 bits or 64 bits, or uses RISC technology, some form of pipelining is often introduced, especially if the chip is executing instructions every clock cycle. If a chip is using a five-stage pipeline, then five different events are happening in the pipeline all at the same time. Building a bondout chip for such a processor is extremely difficult, if not impossible. Finally, as microprocessors operate at faster speeds, in-circuit emulators are less likely to be able to support the higher speed microprocessors.
Another type of design aid available for designers today is a rapid-turn prototyper, such as that provided by Aptix Corporation, and others. These are usually reprogrammable emulators that emulate a portion of the hardware functions of the chip under development. While these can help cut development cycles, they usually do not provide a comprehensive environment for testing and analyzing the system as a whole. Quickturn Systems also provides a rapid-turn prototyper for Application Specific Integrated Circuit (ASIC) chips.
No matter what type of hardware model is employed, if the system under development is a real-time application, such as a chip to monitor fuel-injection in an automobile, the same program, when executed over and over many times in the real world tends to produce different results every time. This is caused by the asynchronous nature of real-time operations, where data coming in from external devices (such as the automobile engine) is likely to be slightly different each time. In a debugging environment, if the hardware model operates in this way, it makes it extremely difficult to replicate the hardware execution states and analyze what has happened during execution. "Intermittent" errors may occur. For example, the application program may operate correctly in the hardware model when the data comes in in small amounts, but fail when large amounts of data are received. To isolate this problem, it would be desirable to have a way to insure that the hardware model steps through handling the same large amount of data in the same time frame so that the flaw in the logic can be identified.
Attempts to help designers model the complete system also include virtual hardware prototypes--also known as software simulators. In these, the microprocessor is often modeled with HDL (Hardware Description Language) or a similar language, to produce a software simulated model of the chip. That is, the resulting "model" is a software program that might perform assembler language or machine language steps such as "if the contents of register 0 are equal to the contents of register 1 branch to the instruction to add the contents of register 2 and to register 3, storing the results in register 3." Some of the additional user's peripherals for the target application can be modeled with HDL as well. However, the simulation approach cannot provide real-time emulation or the opportunity to analyze real-time results, or in-system verification.
This is because software models tend to be quite slow in execution. A set of test data vectors or a test set run on a software simulator usually executes at a speed of thousands of instructions per second, rather than the millions of instructions per second speed at which the chip under development is designed to operate. Complete software simulators that allow system designers to describe both processors, peripherals and other logic can often be costly to create, as well.
In addition, software simulation of a real-time application may not show up bugs or defects that are time-dependent. For example, if three buffers are set aside in the application software to handle data coming in, very fast bursts of data might fill all three in the real world, causing an overflow condition that may not be easy to model in a software simulator.
And, in using either emulators or simulators, it is necessary to create a data set of test vectors or stimulators that can be incorporated into a test program so that the system or chip can be exercised according to a sequence of input patterns. Presently, in order to create test vectors, the system designers must walk through detailed system timings and combinations of input patterns, and project what the system should produce as output given those input patterns. This is usually a very time-consuming process, often taking four to six weeks or more, to accomplish, for reasonably complex systems.
In trying to test systems as a whole, it is desirable to be able to create "what-if" scenarios and then analyze the behavior that results. In the example of fast bursts of incoming data, this could theoretically be described in a software simulator, but, as mentioned, simulators execute at speeds much slower than the real-time events they simulate. In attempting to create the scenario in a hardware model using real peripherals in real-time, identically exact scenarios may never be created, since, as mentioned above, events in real-time may occur asynchronously or unpredictably.
If the details of a given scenario cannot be replicated exactly it is harder or perhaps nearly impossible to find and debug certain kinds of errors.
Testing during co-development of the hardware and software, using several different aids is often complicated further by incompatibilities between the development aids. Ideally, if a database of test data or test vectors is gathered to test the hardware model, it is desirable to use the same sets of data for testing the software model. However, a database of test vectors in the proper format for a hardware model may not be readable or understandable to a software model and vice-versa.
Product development does not stop when the design, simulation, real-time emulation, behavior analysis and in-system verification are completed. Instead, the first steps of product deployment usually occur, in which the "final" product is produced, usually in small to moderate quantities, at first, and placed in field tests or market acceptance evaluations.
Using the fuel injection example, again, it may be desirable to make final products which will be installed in real production vehicles for field testing. If the design has been thoroughly verified in the earlier testing phases, it is likely that the "final" versions of the product will function as intended during field test. If not, the product must be debugged and further testing performed. Even if the product works well in field test, the system may require fine tuning, resulting in hardware design modifications in some cases or application software changes in other situations.
Customers might also require additional functions, or request that the existing functions perform in a slightly different way. An eighteen wheel truck may require a different method of fuel injection and control than that required by a 4 cylinder passenger vehicle. Hence, the same system design may need to be fine tuned for specific requirements for different models.
At the present, once "final" versions of the product are made, most, if not all, of the development aids used in testing them up to that point are no longer useful for testing the product-level implementations of the systems. System implementation of a product-level version of the system is usually accomplished by creating a printed circuit board containing the final chip together with "off-the-shelf" electronic components, or else a custom chip is created in "silicon." That is, a VLSI integrated circuit chip containing all the hardware on one chip is made by a wafer fabricating facility. Existing development aids are not designed to work with these final versions. Both of these processes for creating a final version are time consuming and costly processes, as well. Thus, if a problem occurs after the product is cast in "final" form, debugging it and then fixing it can be expensive.
Some existing techniques for final product implementation allow the designer some flexibility in case a need for changes arises. For example, there are fast turnaround Application Specific Integrated Circuit (ASIC) prototyping systems that let the designer create chips in small quantities, but only for custom user logic. These usually provide custom user logic in a single chip in a few days to a few weeks. However, they generally do not include the microprocessors or peripherals used in the system, only the custom user logic. There are also One-Time-Programmable (OTP) microprocessors which allow the designer to program a microprocessor and certain predetermined peripherals. However, the designer must build the rest of the system, including custom user logic and interconnects, around the microprocessor. Current OTP systems also usually provide RAM or ROM to house the application program storage memory as well, and this may be changeable or programmable in the field. Thus, while the application program code may be changeable in the field test, or final product versions produced by OTP methods, custom user logic and any additional peripherals or interconnects are not.
Another existing approach uses pre-fabricated system modules to achieve fast turnaround for production versions. Pre-fabricated system modules have fixed configurations tailored to specific functions. They are also fixed bus systems. Thus, if the designer needs special peripherals, custom user logic, or unique interconnects (buses), these must be added by means of an additional printed circuit board connected to the pre-fabricated system module.
In other words, while there are fast turnaround techniques that can be used to create final product versions of a system, these, too, are limited in function and flexibility. If the final product includes custom user logic, or a unique interconnect scheme or special or non-standard peripherals, then integration can only be done using a customized chip or customized printed circuit board for the final product version. Presently, there is no fast, easy way to do this. Instead, the designer must commit to an integrated chip design and manufacturing process that includes all these elements using his or her best judgments from the preceding system simulation, emulation, and behavioral analysis steps.
If the customer requires a final product as a single integrated chip, for example, is involves a certain amount of risk in committing to a chip manufacturing process without prior field testing. If the "final" product performs well, in field test, then there is no need to re-spin the final chip. However, if field testing shows up further bugs or flaws in the "final" product, another expensive re-spin may be required.
It is an object of the present invention to provide an integrated development and deployment system that permits the designer to test the whole system and readily deploy and test early production versions.
Still another object of the present invention is providing a system designer with the ability to use development and testing tools with final product versions.
A further object of the present invention is providing a system designer with the ability to create field programmable systems on printed circuit boards or field programmable systems on silicon as field test or final products.
Yet another object of the present invention is to provide a hardware model that is easily reconfigurable as part of the system.
Still another object of the invention is to provide system behavior analysis of the system under development.